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  Accommodating a Maximum Transit Unit/Maximum Receive Unit (MTU/MRU)
                       Greater Than 1492 in the
             Point-to-Point Protocol over Ethernet (PPPoE)

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

IESG Note

   As of this writing, no current IEEE standard supports the use of
   "jumbo frames" (MTU greater than 1500).  Although this document
   contains recommended mechanisms to detect problems in the path,
   interoperability and reliability of non-standard extensions cannot be
   assured.  Both implementors and users of the protocol described here
   should exercise caution in its use.

Abstract

   The Point-to-Point Protocol over Ethernet (PPPoE), as described in
   RFC 2516, mandates a maximum negotiated Maximum Receive Unit (MRU) of
   1492.  This document outlines a solution that relaxes this
   restriction and allows a maximum negotiated MRU greater than 1492 to
   minimize fragmentation in next-generation broadband networks.
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1.  Introduction

   As broadband network designs are changing from PC-initiated PPPoE [1]
   sessions in a combined Ethernet/Asynchronous Transfer Mode (ATM)
   setup, as shown in Figure 1, to more intelligent PPPoE-capable
   Residential Gateway (RG) and Gigabit Ethernet/ATM broadband network
   designs, as shown in Figures 2 and 3, the need to increase the
   maximum transmit and receive unit in the PPPoE protocol is becoming
   more important in order to reduce fragmentation in the network.

         <------------------ PPPoE session ------------------>

                                         +-----+           +-----+
       +--+              +---+           |     |           |     |
       |PC|--------------|CPE|-----------|DSLAM|-----------| BRAS|
       +--+  <Ethernet>  +---+   <ATM>   |     |   <ATM>   |     |
                                         +-----+           +-----+

        Figure 1.  Initial broadband network designs with PPPoE

   In the network design shown in Figure 1, fragmentation is typically
   not a problem, since the subscriber session is PPPoE end to end from
   the PC to the BRAS.  Therefore, a PPP-negotiated MRU of 1492 octets
   is fully acceptable, as it makes the largest PPPoE frame adhere to
   the standard Ethernet MTU of 1500 octets.
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         <----- IPoE -----> <--------- PPPoE session --------->

                                         +-----+            +-----+
       +--+              +---+           |     |            |     |
       |PC|--------------| RG|-----------|DSLAM|------------| BRAS|
       +--+  <Ethernet>  +---+   <ATM>   |     |   <GigE>   |     |
                                         +-----+            +-----+

     Figure 2.  Next-generation broadband network designs with PPPoE

   In the network design shown in Figure 2, fragmentation becomes a
   major problem, since the subscriber session is a combination of IPoE
   and PPPoE.  The IPoE typically uses a Maximum Transit Unit (MTU) of
   1500 octets.  However, when the Residential Gateway and the Broadband
   Remote Access Server (BRAS) are the PPPoE session endpoints and
   therefore negotiate an MTU/MRU of 1492 octets, the result is a large
   number of fragmented packets in the network.

      <----- IPoE -----> <---- PPPoA ----> <- PPPoE session ->

                                        +-----+            +-----+
     +--+              +---+            |     |            |     |
     |PC|--------------| RG|------------|DSLAM|------------| BRAS|
     +--+  <Ethernet>  +---+    <ATM>   |     |   <GigE>   |     |
                                        +-----+            +-----+


       <-------------- PPPoA -------------> <- PPPoE session ->

                                        +-----+            +-----+
     +--+              +---+            |     |            |     |
     |PC|--------------|CPE|------------|DSLAM|------------| BRAS|
     +--+    <ATM>     +---+    <ATM>   |     |   <GigE>   |     |
                                        +-----+            +-----+

   Figure 3.  Broadband network designs with PPPoA-to-PPPoE conversion

   In the network design shown in Figure 3, which is studied by the
   DSL-Forum in the context of the migration to Ethernet for broadband
   aggregation networks, fragmentation is not the only problem when MRU
   differences exist in Point-to-Point Protocol over AAL5 (PPPoA) and
   PPPoE sessions.

   The subscriber session is a PPP session running over a combination of
   PPPoA and PPPoE.  The PPP/PPPoA host typically negotiates a 1500-
   octet MRU.  Widely deployed PPP/PPPoA hosts in Customer Premises
   Equipment (CPE) do not support a 1492-octet MRU, which creates an
   issue in turn for the BRAS (PPPoE server) if strict compliance to RFC
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   2516 [1] is mandated.  For PPP/PPPoA hosts capable of negotiating a
   1492-octet MRU size, then we are back to a fragmentation issue.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [3].

      ATM   - Asynchronous Transfer Mode
      PPP   - Point-to-Point Protocol
      PPPoA - PPP over AAL5
      PPPoE - PPP over Ethernet
      MTU   - Maximum Transmit Unit
      MRU   - Maximum Receive Unit
      PC    - Personal Computer
      CPE   - Customer Premises Equipment
      RG    - Residential Gateway
      BRAS  - Broadband Remote Access Server
      DSLAM - Digital Subscriber Line Access Multiplexer
      PPPoE - client PC, RG, or CPE that initiates a PPPoE session
      PPPoE - server BRAS terminating PPPoE sessions initiated by client
      PADI  - PPPoE Active Discovery Initiation
      PADO  - PPPoE Active Discovery Offer
      PADR  - PPPoE Active Discovery Request
      PADS  - PPPoE Active Discovery Session-confirmation

3.  Proposed Solution

   The procedure described in this document does not strictly conform to
   IEEE standards for Ethernet packet size but relies on a widely
   deployed behavior of supporting frames with Ethernet packet format,
   but exceeding the maximum packet lengths defined by [4].

   Since next-generation broadband networks are built around Ethernet
   systems supporting baby-giants and jumbo frames with payload sizes
   larger than the normal Ethernet MTU of 1500 octets, a BRAS acting as
   a PPPoE server MUST support PPPoE MRU negotiations larger than 1492
   octets in order to limit the amount of fragmented packets in networks
   similar to those described in Section 1.

   By default, the Maximum-Receive-Unit (MRU) option MUST follow the
   rules set forward in RFC 1661 [2] but MUST NOT be negotiated to a
   size larger than 1492 to guarantee compatibility with Ethernet
   network segments limited to 1500-octet frames.  In such a case, as
   the PPPoE header is 6 octets and the PPP Protocol ID is 2 octets, the
   PPP MRU MUST NOT be greater than 1492.
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   An optional PPPoE tag, "PPP-Max-Payload", allows a PPPoE client to
   override this default behavior by providing a maximum size for the
   PPP payload it can support in both the sending and receiving
   directions.  When such a tag is received by the PPPoE server, the
   server MAY allow the negotiation of an MRU larger than 1492 and the
   use of an MTU larger than 1492, subject to limitations of its local
   configuration and according to the rules set forward in RFC 1661 [2],
   within the limits of the maximum payload size indicated by the PPPoE
   client.

4.  PPPoE Discovery Stage

   If a PPPoE client wants to use an MTU/MRU higher than 1492 octets,
   then it MUST include an optional PPP-Max-Payload Tag in the PADI and
   PADR packets.  If the PPPoE server can support an MTU/MRU higher than
   1492 octets, it MUST respond with an echo of the clients tag in the
   PADO and PADS packets when the PPP-Max-Payload tag is received from
   the client.

   Tag-name:   PPP-Max-Payload
   Tag-value:  0x0120
   Tag-length: 2 octets
   Tag-value:  binary encoded value (max PPP payload in octets)

   Tag-description:
   This TAG indicates that the client and server are capable of
   supporting a given maximum PPP payload greater than 1492 octets for
   both the sending and receiving directions.  Note that this value
   represents the PPP payload; therefore it is directly comparable with
   the value used in the PPP MRU negotiation.

5.  LCP Considerations

5.1.  MRU Negotiations

   Since Ethernet (without jumbo frames) has a maximum payload size of
   1500 octets, the PPPoE header is 6 octets, and the PPP Protocol ID is
   2 octets, the Maximum-Receive-Unit (MRU) option MUST NOT be
   negotiated to a size larger than 1492, unless both the PPPoE client
   and server have indicated the ability to support a larger MRU in the
   PPPoE Discovery Stage.

   The initial MRU negotiation for the PPP/PPPoE server MUST follow a
   flow as shown below:
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   If PPPoE {
   PPP_MRU_Max = 1492
   If (PPP-Max-Payload-Tag) AND (PPP-Max-Payload-Tag > 1492)
   Then PPP_MRU_Max = min (PPP-Max-Payload-Tag, Interface MTU-8)
   }
   "Normal" PPP_MRU_Negotiation (PPP_MRU_Max)

   If the PPP-Max-Payload tag is present and greater than 1492, it MUST
   be considered along with the server's interface MTU settings when the
   maximum value is selected for the normal RFC 1661 [2] MRU negotiation
   which decides the actual MRU to use.

   If the PPP-Max-Payload tag isn't present or is present but below
   1492, then the existing MRU constraint of 1492 octets MUST stay
   applicable, thus preserving backward compatibility.

   This, in summary, indicates the following behavior:

   1.  When a "PPP-Max-Payload" tag is received,

      a. the value in this tag will indicate the maximum MRU allowed to
         be accepted or suggested in an MRU negotiation; and

      b. if MRU is not negotiated, then RFC 1661 [2] will set the
         default MRU at 1500.  This will say that the "PPP-Max-Payload"
         tag can have a value greater than 1500, but in this case RFC
         1661 [2] sets the default MRU to 1500, and only if MRU is
         negotiated higher (up to maximum payload) will the "PPP-Max-
         Payload" tag value be used.

   2.  When a "PPP-Max-Payload" tag is not received by either end, then
       RFC 2516 [1] sets the rule.

5.2.  MRU Test and Troubleshooting

   If the MRU is negotiated to a value larger than 1492 octets, the
   sending side SHOULD have the option of sending one or more MRU-sized
   Echo-Request packets once the session is opened.  This allows it to
   test that the receiving side and any intermediate Ethernet segments
   and equipment can handle such a packet size.

   If no Echo-Replies are received, the sending side MAY choose to
   repeat the test with 1492 octets Echo-Request packets.  If these
   packets receive replies, the sending side MUST not send packets
   bigger than 1492 octets for this session.
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   This capability SHOULD be enabled by default.  It SHOULD be
   configurable and MAY be disabled on networks where there is some
   prior knowledge indicating that the test is not necessary.

6.  Security Considerations

   This document does not introduce new security issues.  The security
   considerations pertaining to the original PPPoE protocol [1] remain
   relevant.

7.  IANA Considerations

   This document defines a new value in a space that currently has no
   IANA registry.  There is work in progress to define a registry [5]
   and that document already contains the value assigned here.  No IANA
   action is required for this document.
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